An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hi everyone, I’m currently stuck with a blocking issue in App Store Connect and would really appreciate any guidance or insight. Issue: My app version (iOS App 1.0) is missing the “In-App Purchases and Subscriptions” section entirely. Because of this, I cannot attach my subscriptions to the version, which is preventing me from submitting the app for review. Additionally, I also do not have the option to create a new version, so I can’t work around the issue by moving to 1.0.1. What happened before this: I uploaded a build (Build 24) Submitted the app for review Then removed the submission After that, the IAP section disappeared completely Since then, I cannot attach subscriptions or create a new version Current state: Subscriptions are created and show “Waiting for Review” New Build is attached to Version 1.0 All metadata and screenshots are complete “In-App Purchases and Subscriptions” section is missing “Add Version” option is not available What I’ve tried: Removing and re-adding the build Waiting for UI refresh/processing Contacting Apple Developer Support (case has been escalated for 6 days with no response) Impact: This is currently blocking my app launch because I would be rejected since the subscriptions are not linked, as I cannot submit my first subscription with the app. Questions: Has anyone experienced a missing IAP section after removing a submission? Is there any way to force reset the app version state from the developer side? Is this a known App Store Connect issue? Any help or suggestions would be greatly appreciated. Thanks in advance.

I previously asked in the Network Extension forum about the supported architecture for local, user-controlled domain blocking on unmanaged consumer iPhones. Apple Developer Technical Support explained that using NEPacketTunnelProvider for a purpose other than a VPN is not a DTS-supported use case. DTS also noted that App Review has the final say regarding what may or may not be distributed through the App Store and directed me to App Review for clarification. URL Filters do not provide the intended device-wide domain visibility and user-controlled blocking. At the same time, the deployment restrictions described in TN3134 prevent the use of the relevant content-filtering provider types on unmanaged consumer iPhones. The proposed app is a consumer privacy and security app. It would use NEPacketTunnelProvider to identify destination domains locally and allow the user to block selected domains. The app would not provide a remote VPN service. Network traffic would not be routed to a remote VPN endpoint, and the app would not offer location changing, anonymous browsing, IP address masking, or access to a private network. My questions are: Would this use of NEPacketTunnelProvider be eligible for distribution on the App Store, even though DTS does not support this packet tunnel use case? Would App Review classify this as a VPN service, or could it be classified as a security or content-blocking app under App Store Review Guideline 5.4? If it is classified as a security or content-blocking app rather than a VPN service, may it be submitted by an individual Apple Developer Program member, or is enrollment as an organization required? I understand that a forum response cannot guarantee approval of a future submission. I am trying to clarify the likely classification and account requirement before proceeding with further development.

We currently have version 1.2.0 live and in the middle of its 7-day phased release (automatic updates), currently around the 5% stage. We now want to submit version 1.3.0. I want to confirm the exact behavior before we submit, because I've heard conflicting claims internally. My understanding is: Submitting 1.3.0 for review does NOT affect 1.2.0's ongoing phased release. 1.2.0 continues ramping (10% -> 20% -> 50% -> 100%) undisturbed while 1.3.0 is in review. If 1.3.0 is set to "Manually release this version," it will sit in "Pending Developer Release" after approval and still not affect 1.2.0's rollout -- nothing changes until I actively release it. Only when I tap "Release" on 1.3.0 does 1.2.0's phased release stop, at which point 1.3.0 begins its own phased release from 1%. If 1.3.0 were instead set to "Automatically release this version," it would go live the moment Apple approves it and would interrupt 1.2.0's rollout at that point. Questions: Is the above correct? Specifically, does the act of submitting/approving a new version have any effect on the currently live version's phased rollout, or is the rollout only ever interrupted by the release action? When 1.3.0 is released and 1.2.0's phased release is interrupted, what happens to the users who had not yet received 1.2.0 via automatic update? Do they get queued for 1.3.0 instead? Thanks in advance for clarifying.

I paid the $99 annual Apple Developer Program fee and submitted my first iOS app with the understanding that App Review would normally take approximately one or two days. It has now been six days, and the submission is still sitting in “Waiting for Review.” There has been no review, no request for additional information, no explanation, and no indication that anyone has looked at it. I understand that review times can vary, especially for a first submission, but six days without even entering review seems excessive. Developers are required to pay Apple before they can distribute an app, yet there appears to be no meaningful service-time commitment or communication when a submission remains untouched. Is this currently normal for first-time app submissions? At what point is a developer supposed to conclude that the submission is stuck rather than merely delayed? At this point, I am also wondering whether I should request a refund of the $99 membership fee, since the primary service I paid to access has not been provided within anything resembling the expected timeframe.

My iOS app's first submission (ThymeBlock, Apple ID 6779269775) was rejected under 2.3.2 solely over the OPTIONAL promotional images on my two auto-renewable subscriptions. The required fix, deleting the images, was impossible: both subscription records were locked in "Waiting for Review" and the image field disabled. My reply in the submission thread went unanswered for 48+ hours, so I cancelled the submission (standard advice). The cancel completed, no submission exists anymore, and both subscriptions REMAIN locked in "Waiting for Review", held by nothing. I cannot edit them and cannot delete the flagged images, so resubmitting the app version cannot satisfy the rejection: the change App Review required is impossible to make. Developer Program Support has so far responded with unrelated information, and on a call suggested the subscriptions are in review due to "pending charges from July 18", which seems impossible since the app has never been released and has zero customers. This matches threads 705460 and 717024 (same lock; resolved only by Apple server-side). Case number: 20000117635283. Could App Review or App Store Connect staff release my two subscription records to an editable state, or remove the two promotional image as the rejection requested?

Hi. This is my first time submitting for app review. my app been stuck in “waiting for review” status for over 7 days. Any idea? Any help is appreciated.

Hello, We are a registered software company and have been unable to publish our iOS game for approximately three months because of repeated rejections under Guideline 4.3(a). The first rejection stated that our app shared a similar binary, metadata, and/or concept with apps previously submitted by a terminated Apple Developer Program account. Later rejections repeated similar general wording but did not identify the application, account, source-code component, asset, SDK, metadata element, or design considered similar. Our game is an original Unity project developed by our own team for more than two years. It was not purchased as a template, cloned, reskinned, or repackaged from another application. We possess the complete Unity project, client and server source code, Git development history, design source files, custom assets, backend infrastructure, and all related project files. Our core code, game systems, UX/UI design, and custom visual work were created by our team. Any limited third-party assets or SDKs used by the project were obtained from legitimate sources, and the relevant licenses and purchase records are available. The game also includes substantial custom functionality: • A server-authoritative real-time multiplayer architecture developed by our team • A 51-point opening rule that forms the core of every match • Custom scoring and penalty rules for plays made on other players’ opened tile groups • Matchmaking, table management, reconnect, timeout, and authoritative game-state recovery systems • Multiple game modes and competitive tables • Tournaments and leaderboards • Friends, private messaging, in-game chat, and direct table invitations • Player progression, daily rewards, missions, collectible profile icons, and virtual gifts We use only one Bundle ID and one App Store Connect record. We have not submitted duplicate versions of this application through multiple Bundle IDs or unrelated developer accounts

Hello, Fibo Business Limited’s Apple Developer Program membership was terminated under Section 3.2(f), citing unspecified indications of fraudulent conduct. App name: Kalvero App ID: 6789877937 Bundle ID: com.fibobusiness.kalvero Support case: 20000117968758 Kalvero is an original physical-goods shopping app developed and operated by our company. We have not manipulated ratings or rankings, hidden features, switched the app’s concept after review, offered fraudulent subscriptions, or attempted to evade App Review. The app uses Shopify checkout for physical goods and does not sell digital subscriptions. The dedicated review credentials only facilitate authentication; reviewers and ordinary users receive the same features, catalog, prices, and production backend. We have submitted a formal reinstatement request, but the termination notice did not identify a specific action, build, date, or account association. We understand that account-specific decisions cannot be resolved publicly. Could Apple Staff please confirm that our app submission and support case can be located, and advise whether any additional information is required through the official support channel? Thank you.

Hi everyone, I'm looking for some advice regarding an App Store review delay. Our app was submitted for review on 22 July at 10:30 AM IST. At the same time, we also submitted an Expedited Review Request because this release contains a critical bug fix affecting our live users. As of now: The app is still showing "Waiting for Review" (it has not moved to In Review). It has been more than 48 hours since submission. We have not received any response regarding the expedited review request. We also opened a Developer Support case but the acknowledgment came from a no-reply email address, so we're unable to follow up there. This update is important because our client has informed us that the issue being fixed is currently impacting production users, and they're waiting for this release as soon as possible. Has anyone experienced a similar delay with an expedited review request? Is there any other way to contact the App Review team or check the status when the app remains in Waiting for Review for this long? Any suggestions or experiences would be greatly appreciated. Thank you!

I am planning an iOS security and content-blocking app for unmanaged consumer iPhones. The app would not provide a traditional VPN service. It would not offer: Remote VPN servers Geographic location switching Access to a private corporate network IP-address masking as a service Anonymous browsing Instead, the app would allow the user to: View destination domains contacted by the device Classify destinations such as trackers, advertising, analytics, or potentially malicious domains Manually block selected domains Keep connection history and filtering decisions on the device I understand that NEFilterDataProvider and NEFilterControlProvider are the APIs intended for network content filtering. However, according to TN3134, these providers are not generally deployable for an unmanaged adult consumer iPhone. I also understand that TN3120 says NEPacketTunnelProvider should not be used as a general-purpose local content filter. This appears to leave a gap for an unmanaged consumer security app whose core feature is user-controlled, system-wide domain blocking. I am considering whether NETunnelProviderManager with an NEPacketTunnelProvider could support the feature, but I do not want to use the packet-tunnel API outside its supported purpose. My questions are: Is there currently a supported Network Extension architecture for system-wide, user-controlled domain blocking on an unmanaged adult consumer iPhone? Can an app with this purpose use NEPacketTunnelProvider, or would that necessarily be considered the unsupported general-purpose filtering use described in TN3120? If such an architecture is supported, could an app with this purpose be treated as an approved security or content-blocking provider under Guideline 5.4 rather than as an app offering a traditional VPN service? App Review Guideline 5.4 states that apps offering VPN services must be submitted by developers enrolled as organizations. It also states that parental-control, content-blocking, and security apps from approved providers may use NEVPNManager. For an app that does not provide a remote VPN service but uses Apple’s VPN configuration infrastructure only for local security and user-controlled blocking, must the developer still enroll as an organization, or may an individual Apple Developer Program member submit it?

Dear Apple Review Team & Develpers! Could anyone clarify why Apple Reviewers, when rejecting the app under Guideline 4.3(a) - Design - Spam, do not provide any specific details? Each time my app is rejected, I receive a generic, automated response. In contrast, I provide detailed information and request clarification on the exact reasons for the rejection- specifically, what aspects of the app do not meet Apple's requirements. However, the responses I receive are always the same standard message without any useful details. Am I correct in understanding that the review process is entirely automated, with no human evaluation, resulting in repetitive, unhelpful replies? I would appreciate a more detailed response that can genuinely help me address the issue and ensure my app complies with Apple's guidelines. Here is their standard generic response to any my reply where I provide details and ask questions, but Apple Reviewer answer alsway with the same text: Guideline 4.3(a) - Design - Spam This app duplicates the content and functionality of other apps on the App Store, which is considered a form of spam. Specifically, this app appears to be identical to apps already on the App Store from other developers. Apps that duplicate content or functionality create clutter, diminish the overall experience for the end user, and reduce the ability of developers to market their apps. Next Steps It would be appropriate to revise your app to provide a unique experience or submit a new app that does not duplicate the content and functionality of other apps on the App Store. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and submitting multiple similar apps using a repackaged app template Purchasing an app template with problematic code from a third party Submitting several similar apps across multiple accounts Learn more about our requirements to prevent spam in App Review Guideline 4.3(a). Support Reply to this message in your preferred language if you need assistance. If you need additional support, use the Contact Us module. Consult with fellow developers and Apple engineers on the Apple Developer Forums. Provide feedback on this message and your review experience by completing a short survey. Review Environment Submission ID: c4a62f43-b02a-40f0-b763-e00fcc996512 Review date: March 04, 2025 Version reviewed: 11.4.1202

Does expedited review status carry over to a build resubmitted after a rejection? As I understood the expedited terms it does, but my resubmission has now been in Waiting for Review for three days. App: Hibi Calendar: Daily Journal Apple ID: 6762520622 Submission ID: ab5ae098-30c3-4185-a723-5f7901980dfa Timeline: Mid-July: submitted v3.0, a major update (first iPad build, Apple Pencil, a day-page customization layer). Sat in Waiting for Review over a week. Jul 20: requested expedited review, citing a live marketing campaign. Granted. Jul 21, 1:47 PM: rejected on one issue, Guideline 5.1.1. A pre-permission priming screen used the button label "Grant"; the reviewer asked for neutral wording like "Continue." Build 3.0 (35). Jul 21, 2:54 PM: uploaded build 3.0 (36) with the wording fixed, about an hour later. Today, Jul 24: still Waiting for Review. Roughly three days on the new build, two weeks since the original submission. Two things I got wrong(?), up front: The rejection included the Bug Fix Submissions offer (reply to the thread, keep the current submission). I declined it and uploaded a new binary instead. Believing I was still in the expedited queue, I filed a second expedited request two days after resubmitting. It shows as granted, but nothing moved. I know repeat requests are discouraged. I've also emailed App Review with no reply for over a week, and I haven't cancelled the submission - I don't want to reset the clock over a one-word fix that's already in the binary. My questions: did uploading a new binary rather than replying to the rejection thread drop me out of the expedited queue? Anything actionable on my end, or is the only thing I can do is wait?

Hello App Review team, My app (App ID: 6745896828) was rejected on Friday, July 17. I addressed the points raised and resubmitted the same day. Since then, the build has stayed in "Waiting for Review" with no update or response. This is highly unusual for our account: I have shipped regular updates for over a year, and every single review has been completed within 24 hours. Something appears to be stuck on this specific submission. This is a major version that our partner venues are actively waiting on for a business-critical feature (in-app reservations), so the delay has a direct impact on us. Could the App Review team please look into why this submission is stalled? Case ID: [102945425814] Thank you.

Hi everyone, I'm looking for advice regarding an unusually long App Review process. Our app was initially submitted on July 7, 2026. During the review, Apple rejected the app under Guideline 2.1 – Information Needed because the demo account was not available due to a backend deployment ("User not found"). We immediately resolved the issue by creating and verifying the demo account, replied to the App Review team with the working credentials, and requested an expedited review. However, after providing the updated credentials, our app has remained in the review queue for several days without any further updates. We have also contacted Apple Developer Support and followed up multiple times through the App Review thread, but we have not yet received any information about the current status or whether there are any remaining blockers. This is our first App Store release, and the continued delay is affecting our planned public launch, business commitments, and customer onboarding. Has anyone experienced a similar situation after resolving a Guideline 2.1 issue? Is there any additional action we can take to help move the review forward, or is waiting the only option at this stage? Any guidance or suggestions from the community or Apple engineers would be greatly appreciated. Thank you!

Dear App Review Team, First, I must admit my mistake and sincerely apologize for wasting your time. After my app was previously rejected under Guideline 5.6, I filed an appeal, which was subsequently approved. You instructed me to submit a new binary for review. Due to an error on my part, I submitted a new version and removed the previous submission record; consequently, the new submission was not linked to the ID associated with the approved appeal. I am writing today to provide the ID for my new submission: 0760b84f-00b6-4c77-a1a3-ab9040143c06 The submission ID associated with the approved appeal was: fb5b0474-3ed0-4a38-82c8-3e7553743d1f My App Apple ID : 6764726742

We're hitting a submission deadlock with a Capacitor-based iOS app that I suspect will affect any app using Capacitor/Cordova (or similar frameworks distributed as prebuilt binaries) once Xcode 27 ships. Setup: App built with the current Xcode, targeting the current SDK. Embeds Capacitor.framework and Cordova.framework (via ionic-team/capacitor-swift-pm). The loop: Using Ionic's latest official release: these prebuilt frameworks are still built against an older Xcode/iOS SDK. App Store Connect rejects the upload with ITMS-90111 (stale SDK), even though the app's own target and every other embedded framework are current. To fix that, we rebuilt Capacitor.framework/Cordova.framework from Capacitor's open-source iOS source (MIT-licensed, same version as the official release) using the current Xcode — confirmed via archive that every framework now reports the current SDK. That upload is then rejected with ITMS-91065 (missing signature) — the rebuilt frameworks lack an Apple SDK signature that (as far as we can tell) only Ionic's own build pipeline can produce. So: official release → current-SDK check fails. Self-rebuilt release → signature check fails. We verified this isn't a fluke with an isolated throwaway-archive test swapping only the framework source. Questions for anyone who's solved this: Is ITMS-91065's "Apple SDK signature" requirement satisfiable by re-signing a self-built .framework with our own Distribution certificate during export, or does it specifically require Apple's own build-time signature that third parties can't reproduce? Has anyone shipped a Capacitor/Cordova app successfully against a new major Xcode/SDK before Ionic cut a matching signed release? If so, how? Also filed with Ionic: ionic-team/capacitor#8537 (https://github.com/ionic-team/capacitor/issues/8537) — no response yet as of 2026-07-23.

Hi everyone, I submitted an app update for review on July 16, and the status has been stuck at "Waiting for Review" for a full week now (7 days and counting). The app is not in a sensitive category (not health, finance, VPN, or gambling related), and there are no legal or export compliance issues that I'm aware of. A bit of background: App type: update (not a new app) Submission date: July 16, 2026 Apple Developer Program membership: active and in good standing No messages in Resolution Center or App Store Connect inbox No changes made to the submission during this period (no metadata edits, no new builds uploaded) I understand review times can fluctuate, but 7+ days in "Waiting for Review" — not even "In Review" — without any communication seems unusually long, especially for a routine update. Has anyone else experienced similar delays recently? Is there anything suggested beyond withdrawing and resubmitting (which I'd like to avoid)? Thanks in advance!

Our app has been stuck in "Waiting for Review" with no movement for 10 days. Timeline: July 13: Submitted version 2.0.1 (App ID 6584518186, a stability release) July 18: Resubmitted as 2.0.2 (build 133) with additional crash fixes — same app, same metadata Since then: no review start, no rejection, no metadata request, nothing. What we have already tried: Five (5) expedited review requests — all with concrete justification, zero response A status inquiry through Contact Us (App Review) — no response Review notes and a working demo account are fully provided and verified end-to-end Why this is urgent: this is a critical stability release. Firebase Crashlytics shows our crash-free user rate on the live version dropped to 55% — nearly half of our daily active users experience crashes (1,400+ crash events per 24 hours). The fixes are all in the waiting build. Every day of delay directly harms real users. Questions: Is there any way to find out whether a submission is simply queued vs. placed on an internal hold? App Store Connect shows only "Waiting for Review" either way. Is anyone else currently seeing 7+ day waits? (I've found several similar threads from February and May 2026 with no resolution posted.) Is there any escalation path left when expedite requests and Contact Us both go unanswered? App ID: 6584518186 Any guidance would be greatly appreciated.